• Cloud Summit 投影片：https://docs.google.com/presentation/d/1lYbDdtDmAgNa0U-5zN2BQ7Zf8cNhWsvO-V6NZq0wLVo/edit?usp=sharing
• 官方文件：https://gthulhu.org/

在 Scheduler 層級管理 Kubernetes Workload。

Kubernetes Scheduler 解決了一個核心問題：

一個 Workload 應該執行在哪個 Node 上？

但對許多現代化的 Cloud-Native Workload 來說，選擇 Node 只是第一步。

Workload 被放置到 Node 之後，另一個同樣重要的問題是：

這個 Workload 應該如何取得 CPU 資源？

這正是 Gthulhu 想要解決的問題。

什麼是 Gthulhu？

Gthulhu 是一個 Cloud-Native Workload Orchestration Platform，專注於 Kubernetes Workload 的 Scheduler 層級管理。

現有的 Kubernetes Scheduler 主要關注：

Workload 應該執行在哪裡？

例如：

                    Workload
                       │
                       ▼
              Kubernetes Scheduler
                       │
              ┌────────┼────────┐
              ▼        ▼        ▼
           Node A    Node B    Node C

Gthulhu 則關注另一個問題：

Workload 應該如何取得 CPU 資源？

              Kubernetes Scheduler
                    「Where?」
                        │
                        ▼
                      Node
                        │
                        ▼
                   Gthulhu
                    「How?」
                        │
                        ▼
              CPU Scheduling Policy

Gthulhu 的核心理念是：

Kubernetes 決定 Workload 應該去哪裡，而 Gthulhu 決定 Workload 應該如何運作。

從 Where 走向 How

傳統的 Kubernetes Scheduling 主要回答：

Where should this Workload run?

例如：

• 哪個 Node 擁有足夠的 CPU？
• 哪個 Node 擁有足夠的 Memory？
• 哪個 Node 符合 Node Affinity？
• 哪個 Node 符合 Taints 與 Tolerations？

這些問題都在解決：

Workload Placement

但 Workload 被放置到 Node 之後，Linux Kernel 仍然需要持續決定：

下一個 CPU Cycle 應該分配給哪個 Task？

這時問題變成：

CPU Scheduler
       │
       ▼
哪個 Task 應該執行？
執行多久？
優先權是多少？
何時應該被 Preempt？

Gthulhu 將 Kubernetes Workload 的概念延伸到這一層。

┌────────────────────────────┐
│       Kubernetes            │
│                            │
│  Workload Placement        │
│                            │
│  「Where should it run?」  │
└─────────────┬──────────────┘
              │
              ▼
┌────────────────────────────┐
│        Gthulhu             │
│                            │
│  Workload Scheduling       │
│                            │
│  「How should it run?」    │
└─────────────┬──────────────┘
              │
              ▼
┌────────────────────────────┐
│       Linux Kernel         │
│                            │
│       CPU Scheduler        │
└────────────────────────────┘

Workload Intent

不同的 Workload，對 CPU 的需求並不相同。

一個 CPU-bound 的 Batch Job、一個 I/O-bound 的 Database Service，以及一個 Latency-sensitive 的 Network Function，通常不應該使用完全相同的 Scheduling Policy。

因此，Gthulhu 提供一個重要的抽象：

Workload Intent

Application 或 Operator 可以直接表達 Workload 的特性與需求：

這是一個 CPU-bound Workload。

這是一個 I/O-bound Workload。

這是一個 Latency-sensitive Workload。

Gthulhu 再根據這些 Intent，套用適合的 Scheduling Policy。

┌──────────────────────────┐
│    Workload Intent       │
│                          │
│  CPU-bound               │
│  I/O-bound               │
│  Latency-sensitive       │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│      RESTful API         │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│    Scheduling Policy     │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│      CPU Scheduler       │
└──────────────────────────┘

Gthulhu 的目標，是讓 CPU Scheduling 變得：

• Programmable
• Observable
• Workload-aware
• Adaptable

不同 Workload，不同 Scheduling Strategy

CPU-Bound Workload

CPU-bound Workload 會持續消耗大量 CPU 資源。

例如：

• Data Processing
• Video Encoding
• Scientific Computing
• Machine Learning
• High-Performance Computing

這類 Workload 通常更關注：

CPU Throughput
CPU Utilization
CPU Affinity
Workload Isolation

對於這類 Workload，Scheduling Policy 可以優先考慮如何最大化 CPU 的利用率與處理量。

I/O-Bound Workload

I/O-bound Workload 大部分時間可能都在等待外部資源。

例如：

• Database
• Storage System
• Network Service
• Message Processing Application

這類 Workload 的 CPU 使用模式通常具有不同特性：

I/O Wait
CPU Burst
Wake-up Behavior
I/O Completion Latency

因此，適合 CPU-bound Workload 的 Scheduling Policy，不一定適合 I/O-bound Workload。

Latency-Sensitive Workload

某些 Workload 最關心的不是總吞吐量，而是：

我能不能在足夠短的時間內得到 CPU？

例如：

• 5G Core Network Functions
• Packet Processing
• Real-Time Applications
• Interactive Services
• Low-Latency Systems

對這些 Workload 來說，短暫的 Scheduling Delay 都可能造成明顯影響。

這類 Workload 通常更關注：

Scheduling Latency
Response Time
CPU Isolation
Priority
Predictability

Gthulhu 讓這些 Workload Characteristics 可以成為 Scheduling Decision 的一部分。

Intent-Driven Scheduling

傳統的 CPU Scheduling 通常是由系統根據低階的 Task State 進行決策。

Gthulhu 則希望建立一個更高層次的抽象：

Application Intent
        │
        ▼
Workload Intent
        │
        ▼
Scheduling Policy
        │
        ▼
CPU Scheduling

例如：

{
  "workload": "packet-processor",
  "profile": "latency-sensitive"
}

或：

{
  "workload": "data-processing-job",
  "profile": "cpu-bound"
}

這些 Intent 可以透過 RESTful API 傳遞給 Gthulhu：

Application
    │
    │  「我需要低延遲」
    ▼
RESTful API
    │
    ▼
Gthulhu
    │
    │  Scheduling Policy
    ▼
Linux CPU Scheduler

這讓 Application、Operator，以及更高層的 Orchestration System，都可以用一致的方式表達 Scheduling Requirement。

Kubernetes 與 Gthulhu

Gthulhu 並不是要取代 Kubernetes。

Kubernetes 仍然負責：

• Workload Lifecycle
• Pod Management
• Node Management
• Service Discovery
• Networking
• Storage
• Workload Placement

而 Gthulhu 專注於：

Workload 在 Node 上如何取得與使用 CPU 資源。

┌──────────────────────────────────────┐
│              Kubernetes              │
│                                      │
│  ┌────────┐  ┌────────┐  ┌────────┐ │
│  │ Pod A  │  │ Pod B  │  │ Pod C  │ │
│  └───┬────┘  └───┬────┘  └───┬────┘ │
│      │           │           │       │
└──────┼───────────┼───────────┼───────┘
       │           │           │
       ▼           ▼           ▼
┌──────────────────────────────────────┐
│              Gthulhu                 │
│                                      │
│     Workload-aware CPU Scheduling    │
└──────────────────┬───────────────────┘
                   │
                   ▼
          ┌────────────────┐
          │ Linux Scheduler│
          └────────────────┘

這種分工可以讓：

Kubernetes
    │
    └── 管理 Workload

Gthulhu
    │
    └── 管理 Workload 的 Scheduling Behavior

兩者各自處理不同層級的問題。

Programmable Scheduler

Gthulhu 的核心理念之一，是讓 Scheduling Policy 可以被程式化。

傳統上，Scheduling Behavior 往往依賴固定的系統設定。

Gthulhu 則提供一個 Programmable Interface，讓 Scheduling Policy 可以透過 API 被管理與更新。

概念上：

POST /workloads/{workload}/policy

{
  "workload": "packet-processor",
  "profile": "latency-sensitive"
}

或：

{
  "workload": "data-processing-job",
  "profile": "cpu-bound"
}

這建立了一個清楚的控制流程：

Workload Requirement
        │
        ▼
RESTful API
        │
        ▼
Scheduling Policy
        │
        ▼
Scheduler
        │
        ▼
CPU Resource

因此，Scheduling Policy 不再只是靜態設定，而可以成為一個可以被：

• Application
• Operator
• Controller
• Orchestration Platform

動態控制的系統。

Built on the eBPF Ecosystem

Gthulhu 建立在 Linux Kernel 與 eBPF Ecosystem 之上。

透過 eBPF 與相關的 Kernel Scheduling Framework，Gthulhu 可以將 Scheduling Policy 與 Kernel 的執行行為連結起來。

整體架構可以抽象成：

┌─────────────────────────────┐
│      Kubernetes Workload    │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│       Gthulhu Control Plane  │
│                             │
│       RESTful API           │
│       Policy Management     │
│       Workload Intent       │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│       Gthulhu Scheduler     │
│                             │
│       Scheduling Policy     │
│       Workload Selection    │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│        Linux Kernel         │
│                             │
│        eBPF / sched_ext     │
└─────────────────────────────┘

這種架構讓 Scheduling Logic 可以在不改變 Kubernetes Control Plane 的情況下持續演進。

Scheduling Observability

如果我們改變 Scheduling Behavior，卻無法知道系統正在發生什麼，那麼這個 Scheduling Policy 就很難被真正管理。

因此，Gthulhu 同樣重視 Scheduling Observability。

我們希望可以回答：

哪個 Workload 正在使用 CPU？

為什麼這個 Task 被 Schedule？

Task 等待多久之後才獲得 CPU？

哪些 Workload 正在競爭 CPU？

Latency-sensitive Workload 是否正在被延遲？

傳統上，CPU Scheduling 往往是一個 Black Box：

Application
     │
     ▼
       ?
     │
     ▼
CPU Execution

Gthulhu 希望將這個過程變得更加可觀測：

Application
     │
     ▼
Workload Behavior
     │
     ▼
Scheduling Decision
     │
     ▼
CPU Execution
     │
     ▼
Observability

這建立了一個 Feedback Loop：

Observe
   │
   ▼
Understand
   │
   ▼
Improve Policy
   │
   ▼
Observe Again

為什麼需要 Gthulhu？

現代 Kubernetes Cluster 通常同時執行許多不同類型的 Workload：

High-Throughput Batch Processing
            │
            ├── Network Functions
            │
            ├── Databases
            │
            ├── Storage Systems
            │
            ├── Web Services
            │
            ├── Real-Time Applications
            │
            └── AI Workloads

這些 Workload 擁有完全不同的 CPU Requirements。

一個單一的 Scheduling Policy，很難同時對所有 Workload 都達到最佳效果。

Gthulhu 希望建立一個連接：

Application Requirement
          │
          ▼
    Workload Intent
          │
          ▼
 Scheduling Policy
          │
          ▼
Kernel Scheduling Behavior

也就是：

讓 Workload 表達它需要什麼，讓 Scheduler 決定如何滿足這個需求。

Cloud-Native Scheduling 的下一步

Kubernetes 已經解決了大量的 Workload Orchestration 問題。

但隨著 Cloud-Native Workload 越來越複雜，Scheduling 的問題也正在從：

這個 Workload 應該執行在哪個 Node？

逐漸延伸到：

這個 Workload 應該如何使用 CPU？

甚至：

系統應該如何根據 Workload 的行為持續調整 Scheduling Policy？

Gthulhu 正在探索這個方向。

從：

Where should the Workload run?

走向：

How should the Workload run?

最終走向：

How should the System adapt to the Workload?

Gthulhu

Gthulhu 是一個 Workload-aware Scheduler for Kubernetes。

它不只關心：

Workload 應該在哪裡執行。

更關心：

Workload 應該如何取得與使用 CPU 資源。

透過 Workload Intent、Programmable Scheduling Policy、RESTful API，以及 Linux Kernel 與 eBPF Ecosystem，Gthulhu 將 Kubernetes Workload 管理延伸到更底層的 CPU Scheduling 層級。

Manage workloads not only by where they run—but by how they use the resources that matter.